home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000043_icon-group-sender _Fri Feb 21 20:11:23 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 24 Feb 1997 08:29:56 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: 21 Feb 1997 20:11:23 GMT
  4. From: espie@allege.ens.fr (Marc Espie)
  5. Message-Id: <5ekvhb$7md@nef.ens.fr>
  6. Organization: Ecole Normale Superieure, Paris
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <330DAC29.41C67EA6@solstice.digicomp.com>
  9. Subject: Re: What's the biggest Icon program you've written?
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 4683
  13.  
  14. In article <330DAC29.41C67EA6@solstice.digicomp.com>,
  15. Jan Galkowski  <jan@solstice.digicomp.com> wrote:
  16. >This is an informal and very unscientific survey.
  17. >
  18. >What's the biggest Icon program you've written?  What did it do?
  19. >Do you have any "lessons learned" you'd like to share?
  20.  
  21. A set of functions to manipulate some combinatorial graphs, and display
  22. the result graphically.
  23. Roughly 4000 lines (wc says 3936  11172 82247) for the total.
  24.  
  25. I've got into the main pitfall of Icon: forgetting about failure.
  26. writing stuff such as i <- value & function(i)
  27. forgetting that function(i) was not returning anything, or using
  28. suspended generators, and having them resumed and backtracking and... well,
  29. ending up with the assignment to i being cancelled where it was not
  30. intended.
  31.  
  32. The biggest problems I've run into are some limitations of Icon.  There are
  33. no modules, no import/export mechanism for big projects.
  34. I would also like a better version of itweak... the current one doesn't
  35. deal with undeclared local variables.
  36.  
  37. You end up being somewhat forced to declare local variables... which I hate 
  38. :-(   I would MUCH prefer to have to declare global symbols I want to use
  39. in a procedure, together with a mechanism to `trap' affectation to known
  40. procedure names, and warn the user.
  41.  
  42. I'm also missing features such as manifest constants. The preprocessor is
  43. not such a great solution when you end up with a trace that mentions `2'
  44. and you wrote HIGHLIGHT_COLOR in your source.
  45.  
  46. Idol does have some potential as well.  Pity it is a line-oriented 
  47. preprocessor... Last time I tried it, I ended up with some impossible to
  48. debug mis-mash of code... maybe I should try harder ?
  49.  
  50. >Did you have any efficiency issues to overcome?  Did you use
  51. >coexpressions?
  52.  
  53. I very seldom need co-expressions.  Knowing how they are implemented
  54. makes them somewhat unsafe for `production' code: your process might
  55. crash if it goes into intricate computations, and they don't exist on
  56. every platform.  There is a strange ambiguity there: on one hand, 
  57. small programs usually don't need co-expressions (the rare case such as 
  58. the label generator can be implemented using classical techniques without 
  59. obfuscating the code that much), and bigger programs where they would be 
  60. needed won't be reliable.
  61.  
  62. I'm sincerely hoping they will get better one day. I have a feeling that
  63. Icon could deal with multi-threaded applications very nicely with just
  64. a tweak of the coexpression mechanism.
  65.  
  66. Also, I still like the Icon compiler. In my particular case, I was using
  67. that graph manipulator to do some research on some graphs. Having the
  68. program run twice as fast just meant I could explore bigger graphs.
  69. It would be great if the Icon compiler went some steps further. For 
  70. instance, Icon gobbles lots of memories to tag numerous, small structures.
  71. The compiler could find that these structures are statically typed and 
  72. optimize almost all the way down to C.
  73.  
  74. >Have you ever needed to "sell" Icon to management?  Are they
  75. >distracted by inferior yet more popular and less powerful
  76. >languages?
  77.  
  78. I've somewhat stopped trying to `sell' Icon to anybody... about the time
  79. I stopped selling the Amiga to anybody, for mostly the same reasons.
  80.  
  81. There are some arresting problems.
  82. The fact that Icon is supported by a rather small development team (for
  83. instance, compiler work is stopped) is a problem.  Not being well-spread
  84. is another problem.  Also, Icon can't deal with some things: deeper access
  85. to the system is feasible, but you have to delve into the code to add the
  86. things you need.  This does deter from some of the qualities of Icon:
  87. rapid development.
  88. Also, the Icon book is rather hard to come by, for instance.
  89. You won't find it in specialized libraries, and will have to special-order it.
  90. All this means that Icon has almost a non-image.
  91.  
  92. I do tend to do all my development in Icon/perl/C/C++/PostScript... I use 
  93. Icon as much as I can, switch to perl when this will be faster to code,
  94. C/C++ for anything that craves speed, and PostScript for printing 
  95. applications.
  96. There is such a wealth of perl programmers/perl development these days that
  97. is very difficult to match with Icon. For instance, the text editor nvi
  98. does procure an interface to perl...
  99.  
  100.  
  101.  
  102. >I'm curious about these questions, but I'd also like to see
  103. >the discussion group be more active.
  104. Nice understatement !
  105.  
  106. Did you see my previous posting ?   I'm quite willing to discuss anything
  107. about my coding habits, as shown in X-Tiles.
  108. -- 
  109. [nosave]<http://www.eleves.ens.fr:8080/home/espie/index.html>
  110. microsoft network is EXPLICITLY forbidden to redistribute this message.
  111. `Seiza no matataki kazoe, uranau koi no yuku e.'
  112.     Marc Espie (Marc.Espie@ens.fr)
  113.